FYI: I also put up a PoC for a discriminated union type here #246095

This typing does not enforce that the schema objects contain the discriminator.

Enforcing this makes the types harder as I could not find a variadic type solution, so I ended up with this.

function oneOfKind<
  Discriminator extends string,
  A extends PropsWithDiscriminator<Discriminator, Props>,
  B extends PropsWithDiscriminator<Discriminator, Props>
>(
  discriminator: Discriminator,
  types: [ObjectType<A>, ObjectType<B>],
  options?: UnionTypeOptions<ObjectResultUnionType<A | B>>
): Type<ObjectResultUnionType<A | B>>;

Yeah, I agree that's a nice improvement!

I don't see how this is discriminated based on the discriminator key, this is just a stricter union.

This approach requires exactly one of the provided branches to match the value. If zero or more than one match, the validation fails.

Compared to using alternatives.conditional, which evaluates conditions in the switch array, picks the first matching branch based on the discriminator (or otherwise if provided). Only that branch is applied all others are ignored.

See my solution here.

This approach requires exactly one of the provided branches to match the value. If zero or more than one match, the validation fails.

True, this is an exclusive or hidden under a constructor that will ask for a discriminator key - I believe this is essentially what a discriminated union is.

Yeah but it's not splitting the various schemas by the discriminator. The only discrimination you are doing is within the error handling.

Thus why I think this internal schema is no different than the current oneOf except stricter in that it would not allow multiple matches, much like zod.xor.

Also from a performance perspective, the internals.alternatives(...).match('one') will not short-circuit when a match is found because it needs to validate exclusivity.

But with alternatives.conditional this is not the case as the exclusivity is implied by the exhaustive nature of the discriminator, or more simply it only ever checks one of the schemas.

I agree, from an internal implementation perspective it could match this behaviour more optimally, but viewed as a black box they'd work the same, but good point regarding performance!